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ABSTRACT 

This paper introduces a new technique for dynamic verifica¬ 
tion of component-based real-time systems based on statis¬ 
tical inference. Verifying such systems requires checking two 
types of properties: functional and real-time. For functional 
properties, a standard approach for ensuring correctness is 
Design by Contract: annotating programs with executable 
pre- and postconditions. We extend contracts for specifying 
real-time properties. 

In the industry, components are often bought from ven¬ 
dors and meant to be used off-the-shelf which makes it 
very difficult to determine their execution times and express 
related properties. We present a solution to this problem 
by using statistical inference for estimating the properties. 
The contract framework allows application developers to ex¬ 
press contracts like “the execution time of component X lies 
within 7 standard deviations from the mean execution time”. 
Experiments based on industrial case studies show that this 
framework can be smoothly integrated into existing control 
applications, thereby increasing their reliability while having 
an acceptable execution time overhead (less than 10 %). 

Categories and Subject Descriptors 

F.3.1 [Logics and Meanings of Programs]: Specifying 
and Verifying and Reasoning about Programs; G.3 [ Prob¬ 
ability and Statistics]: Distribution functions 

Keywords 

Design by Contract, runtime verification, real-time systems, 
statistical inference, component-based engineering 

1. INTRODUCTION 

A real-time system is one for which respecting deadlines is 
a part of the system specification. These systems are widely 
used in developing safety critical applications [T] such as 
control systems for nuclear power plants, safety systems of 
automobiles, and avionics. Verifying such systems ensures 


that their behaviors satisfy the specifications. Among oth¬ 
ers, component-based engineering is an approach for devel¬ 
oping real-time safety critical systems [15], [3], [23] and a 
lot of research has been done in verifying these systems [16], 
i, m, i, m- Most of these works are based on model 
checking. Another approach which is better suited for verify¬ 
ing component-based systems due to its support for modular 
abstraction is Design by Contract [181 (annotating programs 
with executable pre- and postconditions) for specifying func¬ 
tional and real-time properties m, m, m, m which can 
be verified using static or dynamic techniques. 

A major challenge in specifying contracts for component- 
based real-time systems lies in expressing the real-time prop¬ 
erties. The existing work in this area focuses mainly on 
checking very simple timed properties which may not be suf¬ 
ficient for representing the behavior of a system. In practice, 
real-time contracts for component-based systems should be 
able to account for all real-time aspects such as availability 
of resources like CPU and memory, exception handling dur¬ 
ing the execution of a component and interactions with other 
components. Another problem lies in reasoning about the 
Worst Case Execution Times (WCETs) of the components. 
Static analysis is a possible approach but it is not easy to 
design and implement a static analyzer that can cater to 
the needs of a particular industrial component-based sys¬ 
tem. Even if one does so, it would not be reusable for other 
such systems. Moreover, static analysis may not be feasi¬ 
ble when the components are bought from vendors and the 
source code is not available m- Another approach is to use 
probabilistic analysis for determining the probability density 
function of the execution times. This is not applicable to all 
systems because the execution time distribution depends on 
the behavior of a particular component. The results for one 
component can not be generalized to all components. 

In this paper we present solutions to the problems of ex¬ 
pressing and checking real-time properties by incorporat¬ 
ing empirical stochastic analysis in the contracts: instead 
of determining the exact WCET values of the components 
or predicting the execution time probability distributions, 
we estimate the WCET values based on empirical distribu¬ 
tion functions and then specify the contracts. Our contract 
framework allows us to specify properties like “ Execution 
time of component X should lie within 7 standard 
deviations from the mean execution time of X" and 
check them dynamically. The mean and the standard de¬ 
viation of the execution times are estimated by statistical 
inference and the parameter 7 is a property of a particular 
component. 
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We validated our approach on a state-of-the-art 
component-based framework, FASA (Future Automation 
System Architecture) [20) developed at ABB Corporate 
Research. Our experiments are based on industrial case 
studies and show that for applications deployed on a single 
host controller, the average execution time overhead added 
due to the contracts is less than 10%, which makes it 
efficient and easy to incorporate on top of any component- 
based real-time application. 

2. OVERVIEW 

2.1 Motivating Example 

We consider a typical control loop with a combination of a 
feed-forward and a feedback controller as our running exam¬ 
ple. Figure Q] shows the schematic diagram for this system. 
The application has a component, Sensor which measures 



Figure 1: A control system with a combination of 
an open loop and a closed loop controller 

the value of a physical quantity, in our case electric current 
generated by System. The feedback loop in our example is 
based on negative feedback because the output current mea¬ 
sured by Sensor is subtracted from the desired current value 
to generate an error. This error is used by the component, 
Feedback controller to dynamically regulate the output of 
the System. The other component is a Feed-forward con¬ 
troller. This controller does not measure the output current 
generated by System and as a result, the latter has no ef¬ 
fect on it. The net effect on the input to System is the sum 
of the effects of the two controllers. In practice, a combi¬ 
nation of a feed-forward and a feedback controller is often 
used for ensuring faster convergence to the desired value of 
the physical quantity being measured. 

2.2 FASA 

FASA (Future Automation System Architecture) is a com¬ 
ponent based framework developed at ABB Corporate Re¬ 
search m used for cyclic real time control applications. A 
FASA application is made up of function blocks (compo¬ 
nents) which communicate with each other through ports. 
Ports can be input or output. A function block receives 
data at an input port and sends out data through an output 
port. An input port is connected to an output port through 
a unidirectional channel. FASA has a centralized scheduler 
which is responsible for scheduling the function blocks on 
the available controllers. The execution of an application is 
triggered by the launching of the FASA kernel which is the 
main entry point to the framework. The function blocks are 
implemented as C++ classes and have a dedicated method, 
operator() where their behavior is described. 

Referring to our running example, the Feed-forward con¬ 
troller, the Feedback controller, the Sensor, the two Addi¬ 
tion Components (shown in Figure |T| with + sign) and the 


System are FASA function blocks. The arrows indicate the 
direction of data flow through the channels. 

2.3 Types of Contracts 

Our contract framework facilitates the specification and 
monitoring of functional and real-time properties. For the 
functional specifications, it supports preconditions, postcon¬ 
ditions and class invariants. It supports loop invariants and 
loop variants for checking the correctness of loops and the 
old construct as used in some languages such as Eiffel ESI, 
which specifies properties about the state of an object. Fig¬ 
ure 03 is a code snippet showing a functional contract for 
Sensor from our running example. Sensor has an attribute 
interval which records the current cycle number. In every 
cycle, this value is incremented by one. Before every up¬ 
date, the current value of interval is saved using the OLD 
macro. In the postcondition, the old value is retrieved us¬ 
ing another macro, GET_0LD which takes two arguments, the 
type and the attribute name. The postcondition states that 
the value must be correctly updated in each cycle. 


class SENS0R_BL0CK 
{ ^ 

int interval; 

void operator() 

{ 

OLD (interval); 

interval = interval + 1; 

> 

void functional_post_conditions() 

{ 

POSTCONDITION (interval == GET_OLD(int, interval) + 1); 

> 

>; 

Figure 2: Functional contract for monitoring the 
state of a class attribute for Sensor from the run¬ 
ning example 

For the real-time specifications, the properties supported 
by our framework are related to: 

1. Execution times of the function blocks. 

2. Cycle times of the control applications: our target ap¬ 
plications are cyclic in nature and since they are safety 
critical, they must not violate the desired cycle time. 

3. Jitter margin: applications must not exceed the max¬ 
imum deviation from the cycle time that can be toler¬ 
ated. This upper limit is called jitter margin. 

The cycle time and jitter margin for industrial component- 
based systems are usually predefined by the control engineer. 
The execution time analysis of the individual components 
is very difficult due to several reasons. First, developing 
a comprehensive static analyzer for WCET analysis which 
can be used for any component-based system is very dif¬ 
ficult. Second, components are often bought from vendors 
and used off-the-shelf due to which their source code may not 
be available. Third, some existing probabilistic approaches 
try to model the execution times of all components using 
a particular distribution function; we executed 24 different 
function blocks from 11 control applications and found that 
upon executing the blocks for 1000 cycles or more, the dis¬ 
tributions converge to a single peak but are very different 
from one another. As a result, it is not possible to fix a stan¬ 
dard probability density function a-priori to model the real¬ 
time behavior of all the function blocks. To overcomes these 
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challenges, instead of using static analysis or a particular 
probability distribution function, we statistically estimate 
the execution time upper bounds and specify contracts us¬ 
ing these estimates. An example of a real-time contract for 
a component in our approach reads like “Execution time of 
component X should lie within 7 standard deviations from 
the mean execution time of X”, where the execution time 
upper bound is computed as a function of the estimates of 
the mean and the standard deviation. Figure [3] shows this 
contract for Sensor. Our approach can be used with any 
component-based system and its performance is indepen¬ 
dent of the size of the application (in terms of the number 
of components). 

struct Real_Time 
{ 

float estimated jiiean; 

float estimated_variance; 

float gamma; 

}; 

Class SENSOR BLOCK 
pubic 

ijit interval; 

Real_Time real_time; 

void operatorO 

{ 

OLD(interval); 

interval = interval + 1; 

} 

void real thne_post conditions!) 

{ 

POSTCONDITION ( EXECUTTON_TII»E «= real_time.estimated_mean 
+ real_time.gamma * sqrt(real_time.estimated_variance)); 


Figure 3: Stochastic real-time contract for Sensor 
from the running example 


3. STOCHASTIC CONTRACTS 

We use statistical inference for analysing the execution 
times of the function blocks and specifying related contracts: 
we estimate the WCET values based on the empirical cumu¬ 
lative distribution functions (cdfs) of the execution times. 
By definition, the cdf of a random variable X is given by: 

F{x) = P[X ^ x] (1) 

where P[X ^ a;] is the probability that the random variable 
X has value less than or equal to x. Let fi and a represent 
the mean and standard deviation of the unknown probability 
density of the execution time of a function block. Using 
equation ID we can find an upper bound tv on the execution 
time such that P[X < T n \ = n where 7 r € [0,1]. Now, t* 
can be expressed as a function of p and a as: 

tv = p + 7a (2) 

where 7 gives us the distance of tv from the mean, p, in 
terms of number of standard deviations, as. Every function 
block is executed for n cycles and the execution times are 
recorded. Let ei, e 2 , e 3 ...e„ denote this sample. The sample 
data is used for determining the empirical cdf. Figure [4] 
shows the empirical cdf of our Sensor, based on 1000 cycles. 
Next, the mean, p n , and the standard deviation, s„ of the 
sample are computed as: 


f-l'Tl - 
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Figure 4: Empirical cumulative distribution func¬ 
tion of the Sensor from the running example based 
on sample size of 1000 

Using equation 0 our framework estimates an upper 
bound, fv on the execution time, if a threshold probability 
0 < 7 r < 1 is given by the application developer. For ex¬ 
ample, if the developer sets 7 r to 0.99, then fv is computed 
so that 99% of the execution times lies within fv from the 
(n + l) th cycle onward. Thus, the accuracy of the bound 
depends on 7 r. Similar to equation ©, r. can be expressed 
as a function of p n and s n as: 

TV — Pn 'ySn (3) 

The reason why we express the bound as a function of p n 
and Sn is that it makes dynamic updating of the bound (as 
explained later) faster. The framework computes 7 only 
once and treats it as a constant while updating p n and s„ 
and re-estimating the bound, fv , p n and s n are unbiased 
estimators m of tv, p and a respectively. This means that 
the expected value of fv is equal to tv and similarly for the 
other two parameters. Following is the formal definition of 
this notion. 

Definition. Let ei, e 2 , es...e n be a random sample drawn 
from a population and let 6 be an unknown parameter of the 
population which is to be estimated. Let 9 = u(ei, e 2 , e 3 ...e„) 
be a function of the sample. By definition, 9 is an unbiased 
estimator of 9 if the expected value of 9 is equal to 9, i. e. 

E[9\ =9 □ 

We use unbiased estimators because they have desirable 
properties m- The proof of the unbiasedness of p n and s n 
are standard results in statistical inference. They are also 
provided in [19]. We use them in the following theorem. 

Theorem. For any given function block, fv is an unbiased 
estimator of the upper bound tv on its execution time. 

Proof. E[ fv] = E[p n + 7Sn] 

= E[pn\ + E[ySn\ 

= E[p n ] + 7 E[s n ] 

= p + 70- 

= tv using equation © □ 

Algorithm ID describes the process for computing 7 . It 
takes the execution time data and 7 r as inputs and returns 
7 . The algorithm sorts and bins the execution times, where 
the number of bins is the square root of the total data count 
and calculates the upper limit for the first bin (line 12 ). 
Then it computes the probability of the data falling into 
the first bin (lines 13-20). If this probability exceeds (or 
is equal to) v, fv is set to the upper limit of the first bin. 
Otherwise, it computes the next bin’s upper limit (line 25) 


SensorBlocklOOO 
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and the process repeats until -k is reached. Ultimately, the 
algorithm returns 7 computed using equation ©• 


Algorithm 1 Empirical Cdf 
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procedure EmpiricalCdf (executiorL-times, n): 7 
sum , y <— 0, 0 

buffer_size <— size (execution_tim.es) 

SORT (execution-times) 

min <— execution_times{ 0] 

max <r- execution_times[buffer_size—l] 

Uni— M I'.A N (exec u ti o n_ ti m e s) 
s n <— Std_dev (execution-times) 
upper-bound max 
number-of-bins <— SQRT (buffersize) 


bin_width <— 


(max —min) 
number_of _bins 


upper_limit_of-bin (execution_times[ 0] + bin-width) 

while upper-limit _of _bin < max do 
while y < buffer size do 

if execution_times[y] < upper -limit, _o f-bin then 


sum 

end if 

y <- 2/+1 

end while 

probability •<— 


sum -\-1 


buffersize 


if probability >tt then 

upper_limit_of_bin 

break 
end if 

upper_limit_of _bin upper_limit_of _bin + bin-width 

sum, ?/ •<— 0, 0 


end while 



return 7 
end procedure 


Once 7 (based on the data from the first n cycles) is ob¬ 
tained, we can specify contracts like “Execution time of func¬ 
tion block X should not exceed 7 standard deviation from 
the mean of X” from the (n + 1 ) th cycle onward. The pa¬ 
rameter 7 is a characteristic property of a particular function 
block. This technique of computing a function block specific 
parameter 7 and using it for specifying the real-time con¬ 
tracts eliminates the problems of using the same probability 
density function to model the execution times of all function 
blocks. 

As the function blocks continue to execute beyond the 
first n cycles, the accuracy of the upper bound may dete¬ 
riorate due to several reasons. First, a function block may 
take longer time to execute due to platform related reasons 
such as waiting to acquire a resource and this might affect 
its execution time. Second, the execution time depends on 
the path of execution followed by a function block: in a cer¬ 
tain cycle, it may have to handle an exception which might 
take longer than usual. Third, the execution time of a func¬ 
tion block depends on interactions with the other function 
blocks and if the other function blocks have a delay, then 
that will affect the execution time of all the interacting func¬ 
tion blocks. To account for these factors, it is important to 
dynamically update the computed upper bound from time 
to time. Since all computations are performed at runtime, 
running Algorithm[T]too many times during the execution of 
the control application would degrade the application’s per¬ 
formance. To prevent this, we only re-estimate /u„ and s n 
at runtime and update tv using the new value of fj, n and s„ 
and the previously computed value of 7 (based on the first n 
cycles). For updating the estimates, we use a sliding window 


mechanism: after a certain number h of cycles, the oldest h 
values of the execution time of a function block are replaced 
by the newest h values and fi n and s n are recomputed. 

4. IMPLEMENTATION 

We implemented the contract framework as a C++ li¬ 
brary. Contracts are checked dynamically. When a contract 
fails, a message is logged. The logging is done by the FASA 
scheduler during the time left in each cycle after all function 
blocks are executed. This time is called the slack time. If 
there is no slack time remaining in a cycle, the messages are 
stored in a buffer and carried on to the next cycle, where 
they are logged before the cycle’s own messages. The con¬ 
tracts are specified within the function blocks in “contract 
methods”. This can be seen in the examples in Figure[2]and 
Figure[3] To test the performance of our framework, we hxed 
an upper bound on the execution time overhead added due 
to contracts as 10 %, consistent with standard practices m 

5. VALIDATION AND RESULTS 

We evaluated our framework on five industrial case studies 
developed at ABB Corporate Research. The applications 
were tested on MacMini computers with 4 GB RAM and 
quad code processors, each core running at 1.8 GHz. The 
operating system was 64 bit Ubuntu 13.04. The results are 
shown for 10000 executions of each application. For the 
real-time contracts, the cycle time was taken as 10 ms for 
the first four case studies and 100 ms for the fifth case study 
in order to handle network communication delays and the 
jitter margin was set to 0.1ms for all case studies. The entire 
list of contracts for each application is available in [Hi- 

Simple Counter. There is a single function block. It 
does not have any ports. An integer variable counter is ini¬ 
tialized to 1 in the block constructor and is incremented in 
every cycle up to 10. For functional contracts, the frame¬ 
work checked a loop variant, a loop invariant and a postcon¬ 
dition to ensure the correct incrementation of counter up 
to 10 in every cycle. For the stochastic contracts, the value 
of the threshold probability 7 r was set to 0.95 and the sliding 
window updating interval h was set to 1 . 

Gaussian Generator. The application generates ran¬ 
dom numbers having a Gaussian distribution. A Random 
Generator block generates two random numbers according 
to Uniform Distribution, [7[0,1]. It then sends the two val¬ 
ues to a Gaussian Generator block which generates two stan¬ 
dard normal, N( 0,1) random values using the Box-Muller 
transformation These two values are sent to a Range Cal¬ 
culator which computes the range of the two Gaussian ran¬ 
dom numbers. The framework checked functional precon¬ 
ditions for verifying the connectivity of the ports for every 
function block before they started transmitting data. For 
the Random Generator, it checked postconditions to ensure 
that the generated random numbers lie within [ 0 , 1 ], as re¬ 
quired by the Gaussian Generator. For the Range Calcula¬ 
tor, a postcondition ensured that the computed range is > 0 . 
The values of n and h were set to 0.97 and 10 respectively 
for the stochastic properties. 

Energy Pack Core Model. This is our running exam¬ 
ple, shown in Figure |T] The application is described in sec¬ 
tion EU The functional contracts included postconditions 

1 http://en. wikipedia.org/wiki/Box-Muller_transform 
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Table 1: Performance summary for five case studies 


Case Study 

Number of contracts 

execution time 

overhead 

without contracts 

with contracts 

Simple Counter 

9 

0.5447 

0.5574 

2.33% 

Gaussian Generator 

27 

1.4202 

1.5161 

6.75% 

Energy Pack Core Model* 

36 

1.7467 

1.8657 

6.81% 

Binary Search* 

43 

1.5865 

1.6761 

5.65% 

Net Proxy: sender 

10 

0.4746 

0.6359 

33.99% 

Net Proxy: receiver 

10 

0.8016 

1.1531 

43.85% 


^median execution time is computed due to outliers in the data. 


for monitoring the states of variables and attibutes, pre¬ 
conditions for ensuring the connectivity of ports and class 
invariants. For this application, 7r was set to 0.95 and h to 

5. 

Binary Search. A Random Integer Generator gener¬ 
ates a random integer which is sent to an Array Creator. 
The latter stores the integer in a dynamic array. It sends 
the array to a Sorter to be sorted in ascending order. The 
sorted array is sent to a Binary Search block. This block has 
second input port where it receives a random number from 
the Random Integer Generator and searches for this random 
number in the sorted array that it receives from the Sorter 
and shows the index of the number if it is found, otherwise it 
prints —1 as the index. After every 10 th cycle, the memory 
allocated to the array is cleared. Thus, the maximum size of 
the array is 10. The functional contracts checked precondi¬ 
tions for the connectivity of the ports and loop variants and 
invariants to ensure the total correctness of the loops in the 
Array Creator, the Sorter and the Binary Search block. For 
the execution time related contracts, n was set to 0.98 and 
h to 5. 

Net Proxy. There are two separate applications 
launched on two separate host controllers. The first ap¬ 
plication has a Sender and a Net Proxy Send block. The 
latter transmits integer values from the Sender through the 
network. The second application has a Net Proxy Receive 
block and a Receiver. The Net Proxy Receive block re¬ 
ceives the integer value from the network and sends it to 
the Receiver. In order to synchronize the clocks on the two 
hosts, the Precision Time Protocol (PTP) is used. For the 
Sender, the functional contracts included a precondition to 
check the connectivity of the output port, a postcondition 
to monitor the state of an attribute and a class invariant. 
For the Receiver, a precondition checked the connectivity 
of the input port and a postcondition monitored the state 
of an attribute. 7r was set to 0.99 and h to 10 for both 
applications. A real-time postcondition checked the com- 
peletion time of the Receiver with respect to the Sender in a 
contract like “Execution of Receiver must terminate within 
0.2ms from the start of the execution of the Sender”, in order 
to account for the network communication delays. 

Table[l]shows the total number of the contracts, the mean 
execution times in ms for the five case studies with and 
without contracts enabled and the execution time overheads. 
The number of contracts include all functional and real-time 
contracts for every function block in the respective applica¬ 
tion m- The execution time overhead for the first four 
applications is well under our 10% limit. For the fifth case 
study, the overhead was more due to delays in the network 
communication (some of the real-time contracts for the Re¬ 


ceiver relied on data obtained through the network). 

6. RELATED WORK 

|25| and [5] describe use of contracts for verification of pro¬ 
grams in Ada. In [7] a tool has been developed for the BIP [3] 
component framework which checks a program against pro¬ 
grammer written specifications at runtime. [5] introduces a 
framework for specifying contracts in temporal logic. The 
use of contracts for distributed embedded system design is 
shown in Hz], None of the above work supports real-time 
contracts for reasoning about metric time. Closest to our 

Table 2: Characteristics of different contract frame- 


works 

functional 

temporal 

stochastic 

updates 

AdaCore|25l 

s 

X 

X 

Hi-Lite[6| 


X 

X 

Barbacci et al.|2| 

■s 

s 

X 

Hartig et al. 1101 

s 

s 

X 

Stierand et al. |27| 

X 

/ 

X 

Sangiovanni-Vincentelli 
et al. |24| 

s 

X 

X 

RV-BIP|7| 

s 

X 

X 

OCRA[5j 

s 

X 

X 

Sojka et al.|26| 

X 

X 

X 

Stochastic Contracts 

s 

s 

s 


idea are the works m and [2] in the sense that both focus 
on specification of functional and timed properties for real¬ 
time systems, but, unlike their tools, our tool does not rely 
only on statically defined contracts. Instead, it updates the 
contracts at runtime to ensure that they remain meaningful 
throughout the execution of an application, taking into con¬ 
sideration the changes in the underlying platform related 
factors. [26] and [24] show contracts in multiple layers of 
real-time systems. The similarity with our work lies in the 
layered structure of the contracts. In our framework, we 
specify real-time contracts in two hierarchical layers: func¬ 
tion block level (WCET related) and application level (cy¬ 
cle time and jitter related). [24] only supports functional 
properties while [26] supports properties related to resource 
reservation. 

To our knowledge, our framework is the first to make use 
of statistical techniques for dynamically estimating and up¬ 
dating real-time contracts related to execution times of an 
application’s components. Table [2] summarizes the charac¬ 
teristic features of the existing contract frameworks which 
are relevant for our research and the characteristics of our 
own contract framework (the final row). 

7. CONCLUSIONS AND FUTURE WORK 
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We presented a statistical inference based approach for 
computing real-time contracts for component-based real¬ 
time control applications. Based on experiments with in¬ 
dustrial control applications deployed on a single controller 
(without network communication), we demonstrated that 
our contract framework adds an acceptable execution time 
overhead (much less than 10%). 

We used statistical inference for estimating upper bounds 
on the execution times of the function blocks. A possible 
extension would be to use machine learning techniques such 
as neural networks and compare the quality of the obtained 
estimates from the two approaches. The challenge in the 
latter approach lies in limiting the overhead added by the 
heavy computations at runtime, either by performing the 
learning offline or by other optimization techniques. 
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